| Package | hl7.ehrs.uv.phrsfmr2 |
| Type | Requirements |
| Id | Id |
| FHIR Version | R5 |
| Source | http://hl7.org/ehrs/uv/phrsfmr2/https://build.fhir.org/ig/HL7/phrsfm-ig/Requirements-PHRSFMR2-S.3.4.html |
| Url | http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-S.3.4 |
| Version | 2.0.1-ballot |
| Status | active |
| Date | 2025-04-03T15:15:30+00:00 |
| Name | S_3_4_Manage_Data_Masking_for_Sensitive_or_Selective_Information |
| Title | S.3.4 Manage Data Masking for Sensitive or Selective Information (Function) |
| Experimental | False |
| Authority | hl7 |
| Description | Allow the PHR Account Holder or authorized designee to mask data on a selective, record, field-by-field, or class basis as one aspect of controlling access to personal health data. The PHR Account Holder has the ability to determine what PHR information is available to an authorized designee. |
| Purpose | The PHR Account Holder or designee needs the ability to protect sensitive information by masking specific content without deleting the information. Example(s): The PHR Account Holder wants to make the fact of Sexually Transmitted Disease or pregnancy known if and only if she arrives at an emergency room unconscious. |
No resources found
No resources found
Note: links and images are rebased to the (stated) source
Allow the PHR Account Holder or authorized designee to mask data on a selective, record, field-by-field, or class basis as one aspect of controlling access to personal health data. The PHR Account Holder has the ability to determine what PHR information is available to an authorized designee.
The PHR Account Holder or designee needs the ability to protect sensitive information by masking specific content without deleting the information.
Example(s): The PHR Account Holder wants to make the fact of Sexually Transmitted Disease or pregnancy known if and only if she arrives at an emergency room unconscious.
| S.3.4#01 | SHOULD |
The system SHOULD provide the ability for the PHR Account Holder to tag records, data fields, or data classes that will not display intelligibly unless viewed by condition-based Authorized PHR Users under conditions specified by the PHR Account Holder. Examples of a condition-based Authorized PHR User include: An individual that the PHR Account Holder specifies, an Emergency Care provider, or a PHR Account Holder's smartphone that is accessed within an Emergency Department. |
| S.3.4#02 | dependent MAY |
The system MAY provide the ability for the PHR Account Holder to manage data visibility at differ degrees of data discoverability by masking, hiding, and/or de-identifying data according to user preference, organizational policy, and/or jurisdictional law. For example: medication information may be masked with asterisks; mental health records may be undiscoverable by those who do not have a need-to-know. Examples of data-masking visibility conditions include: type of healthcare provider (e.g., administrator versus clinician), location of care being received (e.g., a local clinic versus an Emergency Department), time (e.g., weekday versus weekend for a provider), past healthcare service received (e.g., earlier substance abuse therapy; therapy regarding significant weight loss). |
| S.3.4#03 | dependent SHOULD |
The system SHOULD provide the ability to authenticate systems that are requesting personal health information to ensure the requesting system has the ability to protect masked data according to the PHR Account Holder's preferences and consent, organizational policy, and/or jurisdictional law. |
| S.3.4#04 | SHOULD |
The system SHOULD provide the ability to transmit data to other systems that support the ability to protect masked data. |
| S.3.4#05 | MAY |
The system MAY provide the ability to render a notification to the PHR Account Holder that masking selected information may result in unintended consequences or medical harm (e.g., by providing information that is incomplete for a physician who is engaged in the medication-ordering process). |
FHIR{
"resourceType" : "Requirements",
"id" : "PHRSFMR2-S.3.4",
"meta" : {
"profile" : [
"http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/FMFunction"
]
},
"text" : {
"status" : "extensions",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Allow the PHR Account Holder or authorized designee to mask data on a selective, record, field-by-field, or class basis as one aspect of controlling access to personal health data. The PHR Account Holder has the ability to determine what PHR information is available to an authorized designee.</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>The PHR Account Holder or designee needs the ability to protect sensitive information by masking specific content without deleting the information.</p>\n<p>Example(s): The PHR Account Holder wants to make the fact of Sexually Transmitted Disease or pregnancy known if and only if she arrives at an emergency room unconscious.</p>\n</div></span>\n \n\n \n <span id=\"actors\"><b>Actors:</b><br/> ehr</span>\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>S.3.4#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability for the PHR Account Holder to tag records, data fields, or data classes that will not display intelligibly unless viewed by condition-based Authorized PHR Users under conditions specified by the PHR Account Holder. Examples of a condition-based Authorized PHR User include: An individual that the PHR Account Holder specifies, an Emergency Care provider, or a PHR Account Holder's smartphone that is accessed within an Emergency Department.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>S.3.4#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>MAY</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system MAY provide the ability for the PHR Account Holder to manage data visibility at differ degrees of data discoverability by masking, hiding, and/or de-identifying data according to user preference, organizational policy, and/or jurisdictional law. For example: medication information may be masked with asterisks; mental health records may be undiscoverable by those who do not have a need-to-know. Examples of data-masking visibility conditions include: type of healthcare provider (e.g., administrator versus clinician), location of care being received (e.g., a local clinic versus an Emergency Department), time (e.g., weekday versus weekend for a provider), past healthcare service received (e.g., earlier substance abuse therapy; therapy regarding significant weight loss).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>S.3.4#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to authenticate systems that are requesting personal health information to ensure the requesting system has the ability to protect masked data according to the PHR Account Holder's preferences and consent, organizational policy, and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>S.3.4#04</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to transmit data to other systems that support the ability to protect masked data.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>S.3.4#05</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>MAY</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system MAY provide the ability to render a notification to the PHR Account Holder that masking selected information may result in unintended consequences or medical harm (e.g., by providing information that is incomplete for a physician who is engaged in the medication-ordering process).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
},
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
"valueCode" : "ehr"
}
],
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-S.3.4",
"version" : "2.0.1-ballot",
"name" : "S_3_4_Manage_Data_Masking_for_Sensitive_or_Selective_Information",
"title" : "S.3.4 Manage Data Masking for Sensitive or Selective Information (Function)",
"status" : "active",
"date" : "2025-04-03T15:15:30+00:00",
"publisher" : "EHR WG",
"contact" : [
{
"telecom" : [
{
"system" : "url",
"value" : "http://www.hl7.org/Special/committees/ehr"
}
]
}
],
"description" : "Allow the PHR Account Holder or authorized designee to mask data on a selective, record, field-by-field, or class basis as one aspect of controlling access to personal health data. The PHR Account Holder has the ability to determine what PHR information is available to an authorized designee.",
"purpose" : "The PHR Account Holder or designee needs the ability to protect sensitive information by masking specific content without deleting the information. \r\n\r\nExample(s): The PHR Account Holder wants to make the fact of Sexually Transmitted Disease or pregnancy known if and only if she arrives at an emergency room unconscious.",
"statement" : [
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "PHRSFMR2-S.3.4-01",
"label" : "S.3.4#01",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD provide the ability for the PHR Account Holder to tag records, data fields, or data classes that will not display intelligibly unless viewed by condition-based Authorized PHR Users under conditions specified by the PHR Account Holder. Examples of a condition-based Authorized PHR User include: An individual that the PHR Account Holder specifies, an Emergency Care provider, or a PHR Account Holder's smartphone that is accessed within an Emergency Department."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : true
}
],
"key" : "PHRSFMR2-S.3.4-02",
"label" : "S.3.4#02",
"conformance" : [
"MAY"
],
"conditionality" : false,
"requirement" : "The system MAY provide the ability for the PHR Account Holder to manage data visibility at differ degrees of data discoverability by masking, hiding, and/or de-identifying data according to user preference, organizational policy, and/or jurisdictional law. For example: medication information may be masked with asterisks; mental health records may be undiscoverable by those who do not have a need-to-know. Examples of data-masking visibility conditions include: type of healthcare provider (e.g., administrator versus clinician), location of care being received (e.g., a local clinic versus an Emergency Department), time (e.g., weekday versus weekend for a provider), past healthcare service received (e.g., earlier substance abuse therapy; therapy regarding significant weight loss)."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : true
}
],
"key" : "PHRSFMR2-S.3.4-03",
"label" : "S.3.4#03",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD provide the ability to authenticate systems that are requesting personal health information to ensure the requesting system has the ability to protect masked data according to the PHR Account Holder's preferences and consent, organizational policy, and/or jurisdictional law."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "PHRSFMR2-S.3.4-04",
"label" : "S.3.4#04",
"conformance" : [
"SHOULD"
],
"conditionality" : false,
"requirement" : "The system SHOULD provide the ability to transmit data to other systems that support the ability to protect masked data."
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "PHRSFMR2-S.3.4-05",
"label" : "S.3.4#05",
"conformance" : [
"MAY"
],
"conditionality" : false,
"requirement" : "The system MAY provide the ability to render a notification to the PHR Account Holder that masking selected information may result in unintended consequences or medical harm (e.g., by providing information that is incomplete for a physician who is engaged in the medication-ordering process)."
}
]
}
XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.